I’m interested in hearing from our users: how do you trace requirements for your Solid Edge designs?
For example, suppose I have a functional specification document that contains all of the requirements for a given project. It tells me things like, “the handle should support 50 kg,” “the total weight should be no more than 10 kg,” and “the material should be corrosion resistant.”
Next, I create or modify my models in Solid Edge so that they satisfy these requirements. Before the design gets sent to manufacturing, someone has to check the models to determine A) what requirements they are supposed meet, and B) whether the requirements have been met.
So, how does the checker find the requirements for each model, or vice versa, the models that meet each requirement? On the other end, what if a failure happens out in the field - how do I trace a part number back to a requirement that led to this failure?
What would be a good system for doing this? What kinds of problems have you encountered with tracing requirements?
Part numbers and revision are the main way to track things. Manufacure date can also be important.
Part number and revision definitely help here. So does each requirement in the functional spec get a list of part numbers that satisfies that requirement?
Use the "Binder" command, to connect the documentation to the SE file.
Binder does come in handy. Downside I would see is if you want to save a revision of the functional spec, then you may need to go update the Binder links for the affected SE files, e.g., Spec-100_A.doc -> Spec-100_B.doc.
Yes, indeed there is Teamcenter Requirements Management. Wondering if any Solid Edge users have tried it out and what your experience has been like? Or, any alternatives you've tried.
The baseline is the warehouse.
First of all, the requirements HAVE to be documented. If they are not documented, validated, and verified, then they really aren't requirements. Verbal requirements aren't requirements!
Now that you have a requirements document (or controlled content created in a requirements management system), you can "link" that document to the item that resolves that requirement. The link is done through the baseline where the physical item is the storage container for the documents that define it.
Take a look at a recommended format for structuring physical items with their respective documents. I'd be happy to introduce you to the proper individuals to develop this concept further within Siemens' products. (Excel is not a valid filetype for inclusion, so I'm afraid you only get the pdf.)
Hello Mr. Jenkins,
The requirements, gathered customer data, references to existing products pretty much all come from sales and are documented in the PDM (everything but CAD data) side of the ERP database. That information is also linked within the database to the Engineering Project(s) that are/is being driven by the requirements. It is up to the assigned Engineer to make sure requirements are met (most projects are small scope and only have one Engineer working on them.) A sales drawing and model are typically sent to Sales and forwarded onto the customer for approval before a prototype order is entered. It is possible/likely that Manufacturing will receive the engineering data concurrently for quoting, tooling and material needs for prototype phase. If there are purchased parts Purchasing will also be involved to get pricing and PREQs started for prototyping. All of that manufacturing and purchasing data lives in specific formats in the database. Those steps will vary in concurrency depending which market the product is for and lead time demands from the customer. In other words we follow one of several documented processes for new or modified products, but will start "multi-threading" the project when we expect lead time issues on the prototypes. It's a friction area dealing with shorter design cycles and an increase in new design requests due to shorter product life cycles all the while trying to keep CAD product data synchronized with the product data that lives in the rest of the database system.
My $0.02 understanding of it.