I took BME capstone during my undergrad at NJIT and the requirements document and test plan documents are both things that I've seen and worked with since I started working. When I worked in a test analist role I was required to read and understand all requirements pertaining to my module. The requirements came from different findings from customers including observations they raised and things they wanted to see, this is where the customer needs were obtained and turned into requirements by the BA team. I had to use requirements and create test cases based on them and all test cases were stored in the test plan.

I was also an undergrad at NJIT and went through the senior capstone design course and agree that the test plan and business requirement documents were time-consuming to complete but there is great value in the experience we received from completing these documents. In any business, it is extremely important that all staff keep clear, clean, and precise notes on the project that they may be working on or responsible for. The main reason is that if anyone else had to pick up or join your group/project they would easily be able to follow the project and understand all parts. This is why during capstone we had to revise out test plan and business requirements 3-4 times after multiple peer/classmate, professor, and advisor reviews. Basically, we learned that anyone should be able to pick up these documents and complete your project based on what they read, hence making the documents “idiot proof”. As Dr. Schesser always said, “the devil is in the detail.”

I am currently a senior in Capstone. The procedures that we are exposed to when it comes to Customer Needs, Business Requirements and test plan is meant to mimic that of the industry. Formatting that class in more of an industry device development vs academic research is very beneficial t student. I myself have been involved in a lot of academic research but was never greatly exposed to paperwork that companies go through. We had two different guest speakers come speak with us about the process of a test plan, along with many students who have worked in industry. They explained that process is we are planning on going through is very similar to that of the industry. The only differences are the names that give each step and document. This is very beneficial to have in your toolbox, especially when it comes to interviews and advertising you to the market for a job. Having prior experience on this makes a new hire less of a risk and a better overall future employee. We learned early on the importance of keeping documentation and keeping notes especially when executing a plan, having plans that are easy to follow makes it easier on us for the future, makes it easier on our colleges and especially future auditors. These skills are very important to have and this class gives us a good amateur taste.

Currently in capstone this semester, I see the importance of the business requirements. We have yet to create test plans for our device. Through the detailed business requirements, someone not familiar with your product should have the ability to recreate it to some extent. All of the details must be quantitative if possible, and qualitative where it is not. Through this document, the device comes to reality as something that could possibly really be on the market.

At my company, we document user requirements in its own document. The user requirements also drive design input requirement and are linked via a trace. When an input requirement is changed or modified, we also evaluate potential impact to the user requirements or if re-verification is required. Similar to the design inputs the user requirements are specific but a little more high level, like a a wish or a feature.

In the company I work for, I've seen several user requirements documents as well as risk analysis forms which include user requirements embedded with defined risk levels. User requirements documents help define the product because they come from the customer's needs. It is our job to translate the need of the customer into tangible specifications which the team can work with. With that being said, these requirements are not only included in the user requirements document but also the test plan where the requirements are assessed against each subsystem, component, overall system to ensure that the product does meet the user's needs.

I also am taking capstone, where the requirements are the same. I am working with another orthopedics company in hopes of finding a way to create a product that fits their requirements and works well with the body. Along with customer needs, they also have specific design requirements that need to be met and created. As a result, my group and I spent hours designing and scraping drawings that seem to fit their requirements. We also set up weekly meetings in order to ensure that the design requirements are being met. With their approval, we can move on the creating the actual design and testing it in order to make sure their other design requirements are met. I feel that the weekly meetings and updates are absolutely necessary to ensure that something is getting done and that it is being done efficiently.

I agree with most of the participants in the above posts. During my senior design class at NJIT, I learned more about the requirement and the test method documents and its importance. My professor constantly stressed every class that the requirement and the test plan document must be “idiot proof” and easy to understand. Requirement document has specific details from the end user or the customer and test plan consists of steps of multiple tests to prove each customer requirement. Both of the documents must be very detailed so if someone’s to test for each requirement, he or she should be able to perform without any assistance. In my industry experience, I’ve found this very helpful. For example, there are inspection plans for each operation of the manufacturing process to test the requirements. The inspectors must be able to test the part with the applicable test methods written on the inspection plan. The Quality Engineers creating the test plans are very detailed as they are busy supporting other activities throughout the day. To summarize, all documents must be clear and detailed in the medical device industry, it also makes it easy for Quality Manager to explain in an audit.

I am currently in Capstone I, and we have completed the phase of customer needs and business requirements. This phase is very similar to the process in industry, as we are learning in the course. Through gathering customer needs, we could identify what a customer would need when developing the product. These needs are specific yet contain no solutions so that it is open-ended, and there are multiple solutions for a single problem. The business requirements then follow to detail how this product will be made. The test plan has not yet been explored but this explains how the hardware and software will be carried out.

These three documents were the backbone of the entire Capstone project. These documents follow the project's journey from it's conception to its completion. The requirements document describe the project's overall characteristic from its physical characteristics to its technical features. These requirements were all based off of the customer needs that were gathered from researching the features about your competition and improving upon them. The Test Plan verifies that the design for the project meet the requirements stated on the requirements document. Also, these documents are what we call "living" documents because of the continuous development or innovation of the products that these documents describe.

I am currently in Capstone 1 at NJIT. The business requirements document is very important because it is takes the customer needs given to us and puts us on a path to create a product. I do believe that all medical devices do go through these steps because it is a great way to make the best product. But almost every time the best product is not made because products can always be improved especially if technology is growing. By using the documents we can keep in order the customer needs and all the specifications of each product which in the long run can help when improving the product. So as tedious as these documents and the process as a whole are it can be very helpful down the road.

I'm so glad that we have capstone as a required class. I think it would be really nice if we got to do a capstone project for each year that we are in college. That way we would have the opportunity to expose ourselves to multiple projects that fall within the different tracks of BME. I feel like capstone gave me a good understanding of how projects are initiated and the products are brought to the market in the end. Having that previous knowledge makes it easier for me to to understand the contents of this class, especially this week's lecture as @jtl27 already mentioned. Knowing how to make a product requirements document based on customer needs, understanding what design controls are and coming up with test plans that we can use to test the requirements of our products helped me a lot with my interviewing process at the company that I applied to as well.

Being part of capstone instilled in me the practical and technical skills of writing a DDP and how you must use “shall” in the document. Also, if you make changes in one document say the DDP then you will have to make those changes in DSD. I understand why change orders are not favored.
Being part of NSF I learned the business approach to selling your idea to customers and companies. In order to make a device their needs to be a need that’s the classical model. In other cases theirs wants that we never knew we needed and this has become more of modern model of customers needs. Anyway, I learned you need to ask everyone what they think of your device and/or technologies or whatever is and get their input. The consumer is the person buying the product its free advice that goes a long way. Examples are going to trade shows, conferences around the world, anything that helps to get customer input.

The Business requirement document I will say is the combination of the Design Input Documents (DID) and the Design Specification Documents (DSD). Business requirement document just like what have been said above is a major requirement and guide to a Quality device to be produced. Since all the information in the Business Requirement Document basically comes from the customer’s inputs, who definitely know what they want and how they would like a device to be made. That been said is not a guarantee that this will all have a perfect output of a device just because you have a perfect Business requirement document. Human errors can hinder this in some way. Something can be missed and not seen as a problem at the get go. 

The test plan then comes in to make sure that all that was in the Business Requirement will work accordingly as planned and give a perfect output. That been said both are very essential parts of a Medical Device that should never be over looked, this will help to produce a perfect or almost perfect device and then when produced, validation comes in to make sure that the device created is still within specs and works as planned years after production. 

In sum, Business Requirements and Test Plan helps to satisfy the customer needs in terms of quality and perfection. 

I agree with the comment that the DID and DSD documents will not guarantee a quality medical device product. The overall process beginning with the voice of the customer (VOC) a term from Operational Excellence is the beginning. The efforts of Design Input is a collaborative effort with numerous team members from different perspectives. Followed by the design specification, then verification and validation documents. In my years in the pharmaceutical industry, I have learned taht the ability to continually collaborate across the organization and enable traceability of the activities to the VOC is the primary approach to ensure we have a quality product.  We need to ensure that the medical device is meeting the needs of the customer/client. Utilizing good documentation practices within a well defined process is necessary. I know folks do not like to be bound to a tight process and documentation but when we are dealing with the impact to patients, it is well worth the investment.