cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X

Business Requirements Document Format

pwilliams-3
11-Garnet

Business Requirements Document Format

Hi all,
When implemented Windchill for the first time how did you capture the business requirements, software requirements and technical design? Did you connect each of them together to provide traceability from a business requirement down to the technical design? I'm looking for techniques and formatting answers to this question. Thanks in advance.

Patrick Williams | Engineering Systems | c: 616.947.2110
[cid:image003.jpg@01CDA855.978E14D0]

2 REPLIES 2

This is exactly what I'm trying to do right now! There must be a way. I think it's just some grunt work to lay it out in a useable fashion.



Lewis Lawrence at Weatherford made an excellent presentation in the 2012 conference which presents the need for this clear cascade from Business Requirements to System design.



See CUST137_WC_Making_WC_Perform_for_an_Enterprise_Lawrence.pdf from the archive documents that can be downloaded from this PTC user site.



PTC Also has documents about this and does speak in general terms about the necessary steps and processes in their PTC U courses.



Additionally there is the "Business Process Modeling and Monitoring Planning Guide
Enterprise Deployment Resource" available from the Resource document section of PTC support (Select PDMLink, Enterprise Deployment Resources). In that document on page 26 it says:



Utilize a requirements matrix document to record, validate and track all identified requirements. Adopt a formal numbering scheme for requirements so they are easily identified, tracked and managed. Consolidate the requirements to eliminate any duplication or overlap, and place into a hierarchy to provide structure and manage decomposition. Requirements should also be categorized, and generally fall into four main groups...



I guess reading and understanding the rest of that document would lead one to making a Requirements Matrix that it discusses. I haven't found an example of such a document so far. Perhaps others have?


cc-2
6-Contributor
(To:pwilliams-3)

Very good question.



I agree it should be driven per the business PLM strategy first. For our case, the logic went from a basic cost saving exercices.


Let replace all sort of CAD systems per one only. It happened to be ProE and we got solved Intralink but never used it as a PDM. Just as a dump and when Windchill became more evalable we got to replace Intralink.



This is obviously not the right approach even if Windchill is more than capable is handling our case.



My approach would be first


define a PLM strategy. Why do you want PLM for (cost saving, manage capital, design anywhere, manufacture anywhere, reduce time to market etc....)


Once decided, which business process can support this


Then which system or technology can best support this business process, how much can be done automatically


What does it mean in term of data migration and translation



Also very important. Where are you starting from.


Map your above identified processes if not already done. If you have them already, check them. Often they have been written years ago but things change. Once happy, try to time and cost them. ie how long each part of your process last (actually time and allowable duration), how many automated activities vs manual activities and icing on cake, try to cost all this. Either cost each activity or the overall cost.



Once you have all this.


Try to find a system which will not only support your process but will allow you to improve it (that accepting that you may need to change your current processes because of the new system but also because it will improve your processes).


Once you have identified your system.


you need to create a process map using this new system.


Here again, time them and cost them.


then you can compare. It is very important to be able to compare because you need to justify you are going in the right direction.


(For us we made progress but we did not properly keep record of where we started from, many people now take things for granted, complain about what they have but they forget about how it was)



Ideally you should be in a situation where some activities got dropped (maybe new ones added) but the duration should be a lot less as well as the cost.



This said, there is something else to consider. Maybe your current process was only concerned with the departments and the teams based at the same site but in realilty other people are involved. The new engineered process should take this into account to ensure maximum efficiency and therefore maximum return.




I believe this is actually the most difficult part of a PLM implementation. Once you have your system and new processes, it should be very easy. migrate some data and train the users 😮



Best of luck.


Top Tags