SBS - The Best Value in QMS software

Design Review OR Design Change - Software development company

A

Ajayqms

#1
Hi all,

Please help in understanding one requirement, for which I providing one example (for understanding)

A software development company, starts development of software after geting the requirement document from customer.

They prepare good Design Planning
Design Input
Design Output
Design Verification - Internally verified by Project Manager and Externally by customer itself.
Design Validation -Internally by QA team and externally by client.

However while testing the product, customer sees that the functionality should change little bit or the display or screens or validation points should be modified.

Now whether we should consider them as a design review and incorporate the requirements of customer or whether we should start with Design change (and MIND IT still the design is not validated).

Kindly let me know your views, however in case of any clarification on above situtation let me know.


:bonk:
 
Elsmar Forum Sponsor

jelly1921

Quite Involved in Discussions
#2
Re: Design Review OR Design Change

Design and development (DD) review is used to evaluate the ability of the results of design and development to meet requirements, and to identify any problems and propose necessary actions (in order to make the DD have the ability tomeet requirements)

In the case you mentioned, it is not DD review, because there is no evidence that DD is not able to meet the previous requirements, but DD change, because the requirements has been changed. Therefore, you have to review, verify, validate, as appropriate, and to be approved before implementation.

Jelly
 
A

Ajayqms

#3
Re: Design Review OR Design Change

Thanks for your fast reply, but if the case, then in a complex customized application software, these kind of iterations are many in numbers, and practically there is no need to review, verify, validate the things.

Further these are creating this type of documentation, it is a tiresome activity and organisation always do it with design review at accomodate change or modify the current things with details maintained who has changed, when it is changed, and what he has changed under CVS system, above all the reason is discussed in design review.

Still u think that it is design change instead of design review.

Ajay:bonk:
 
C

Chris Ford

#4
Re: Design Review OR Design Change

Thanks for your fast reply, but if the case, then in a complex customized application software, these kind of iterations are many in numbers, and practically there is no need to review, verify, validate the things.

Further these are creating this type of documentation, it is a tiresome activity and organisation always do it with design review at accomodate change or modify the current things with details maintained who has changed, when it is changed, and what he has changed under CVS system, above all the reason is discussed in design review.

Still u think that it is design change instead of design review.

Ajay:bonk:
Ajay,

I think this really boils down to how your company defines design change and design review. Design review is typically a verification activity. If the customer's requirements have changed, your design control system should be able to accommodate that. Obviously, especially in software design, design change doesn't occur only after the design is complete and validated. We'd expect to see many iterations of the software design life cycle. You encounter bugs or other anomalies, address them, etc. But, if the top-level requirements change along the way, you'll need to update your requirements document along with the risk analysis. Then you can assess the impact on your validation requirements. But, the point is you don't need to make this a "major event". It can be as simple as updating your requirements and risk documentation and moving on... well you'll have to update your project plan too, of course. So, in this case, since you've already validated the design, address it as a change then develop your validation requirements for the change.
 
A

Ajayqms

#5
Chris,

The requirements to be incorporated are not new (mostly) and there is no major change in design logic and documents, however it is incorporation of small suggestions, as you know company already prepare the design output after understanding all the customer requirement through their SRS document and by visiting client site. But these small changes normally customer doesn't visualize in early stage of design verification, then why again to review, verify and validate and of course start design change requirements, basically I am not designing any thing new here so why to verify and validate again.

Kindly be clear that the requirements are very small like adding report, changing font, changing the sequence of windows, however their is no logic or design change..

Ajay:bonk:
 
C

Chris Ford

#6
Chris,

The requirements to be incorporated are not new (mostly) and there is no major change in design logic and documents, however it is incorporation of small suggestions, as you know company already prepare the design output after understanding all the customer requirement through their SRS document and by visiting client site. But these small changes normally customer doesn't visualize in early stage of design verification, then why again to review, verify and validate and of course start design change requirements, basically I am not designing any thing new here so why to verify and validate again.

Kindly be clear that the requirements are very small like adding report, changing font, changing the sequence of windows, however their is no logic or design change..

Ajay:bonk:
Hi Ajay,

While small, they're still changes. It doesn't seem that validation would be necessary, but you'll still verify the changes, won't you? In other words, you've got a set of new requirements... they don't require validation. After you've implemented the new requirements, you'll still need to go back and verify (i.e. customer approval or some sort of QC??) that the new requirements were met.

My main point is that your design control system should define these requirements. It should be robust enough to allow for flexibility in the design process while handling changes and deviations in a manner commensurate with the level of risk imposed. So, if it's no risk / no impact and doesn't change the fundamental design, you wouldn't need to revalidate. Depending on the significance of the change, your process would allow you to handle changes in a variety of ways.

I'm working with a client now that develops Class III software medical devices. I'm designing their design control process now with the same ideas in mind.
 
A

Ajayqms

#7
Dear Chris,

That is what I told, there is no requirement for customer verification, only the required change in the application through design review, and finally acceptance of customer on the new change (part of validation).

There is no new requirement given by customer and absolutely design logic same.

If you want to review design formats kindly let me know.

Regards

Ajay:bonk:
 
C

Chris Ford

#8
Dear Chris,

That is what I told, there is no requirement for customer verification, only the required change in the application through design review, and finally acceptance of customer on the new change (part of validation).

There is no new requirement given by customer and absolutely design logic same.

If you want to review design formats kindly let me know.

Regards

Ajay:bonk:
Hi Ajay

Just to be sure we're talking about the same subjects here:

ISO 9001:2000
7.3.4 Design and development review
At suitable stages, systematic reviews of design and development shall be performed in accordance with planned arrangements (see 7.3.1)

a) to evaluate the ability of the results of design and development to meet requirements, and
b) to identify any problems and propose necessary actions.

Records of the results of the reviews and any necessary actions shall be maintained (see 4.2.4).

and ISO 9001:2000
7.3.7 Control of design and development changes
Design and development changes shall be identified and records maintained. The changes shall be reviewed, verified and validated, as appropriate, and approved before implementation. The review of design and development changes shall include evaluation of the effect of the changes on constituent parts and product already delivered.

Records of the results of the review of changes and any necessary actions shall be maintained (see 4.2.4).

My understanding of your situation is that during validation of your software, your customer noted several features it wanted changed.

At that point, you analyzed the request and determined it consists of several minor changes that do not impact the system requirements document, the architecture, or any known hazards, and the changes won't raise additional hazards.

You're asking if this can be handled during a design review under 7.3.4(b) which basically states that problems are identified and actions proposed during design review. If I were documenting the change under this section during a design review, I would document the evaluation (no new impacts), then state the rationale for not performing a verification (ie. minor change that can be verified during validation). In the end your customer will sign off on the validation accepting the design with the requested changes.

If you want to handle this under the design change section, you would do exactly the same thing, except document it as a design change. I think your issue is that this request is so minor, you can't figure out quite what to call it!

In either case though, document your rationale and results of your reviews, then the rest should come out in validation. You might want to consider evaluating your design control procedure to allow for things like this.
 
A

Ajayqms

#9
Dear Chris,

The situation is because of these changes there are no design change in logic, data base or other base design documents, may be front end modification and other minor requirement of few information during analysis in software (required by client), same is reviewed in design review, action decided by team along with responsibility and target date and then after completion it is being forwarded to customer for validation (no verification) of of his requirements.

Now let me know your suggestion, and I would prefer other members to participate in discussion.


Ajay:bonk:
 
D

danpa

#10
Ajay,
To me you have a Design (big 'D') change. While your companies software design (little 'd') documentation may not have changed, the Design of the product is being changed based on your validation (excellent). When the Design of the product changes, your system needs to define how those Design changes get incorporated into the product.
Most software companies that I know, say something to the effect of, "when a Design change is identified, we will enter the DD process at the appropriate phase and updated all design documentation that is appropriate to the change being made." So, if the requirements changes, we go back and reenter the requirements phase, if detailed design is the highest level of the process changed, then we reenter detailed design phase, etc.

It really doesn't matter what you call it, your development team needs to update the appropriate documentation and do the appropriate downstream reviews and V&V based on your companies process - if the only thing changed is the code then that is what changes and gets reevaluated and then V&V'ed.
I would suggest, that your design documentation may be lacking if changes like this do not effect any documentation higher than the code, but that is my opinion for the type of products I deal with. If this information is not in any Design documentation and only the code, your validation is likely going to be very important and likely difficult to get through due to multiple "validation bugs" found very late in the D&D lifecycle.
Dan
 
Thread starter Similar threads Forum Replies Date
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
C Design Transfer Review - Before or after PQ validation? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
M Does a CDR (Critical Design Review) have to have a moderator that is unconnected to the team? Design and Development of Products and Processes 4
A What to expect in a Design Dossier Review for CE Marking by a Notified Body CE Marking (Conformité Européene) / CB Scheme 3
S Annex II List A - Notified Body Fees - Design dossier review and batch release EU Medical Device Regulations 2
G ISO 14001 & Product Design Process Environmental Aspect Review Requirements ISO 14001:2015 Specific Discussions 7
H How to make the Design Review Process Effective Design and Development of Products and Processes 1
H Form that will satisfy Design Review and Design Verification Requirements (7.3) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
P Please Review my Design and Development Plan Design and Development of Products and Processes 2
P How to separate Product Design Review, Verification, and Validation Activities ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 26
M 7.2.2 Review of Requirements Related to the Product (Design-Manufacturing Service) AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 4
M MHRA (Medical & Healthcare Regulatory Agency) Design Dossier Review Delays EU Medical Device Regulations 2
L Time and Cost for a Notified Body to review a Design Dossier ISO 13485:2016 - Medical Device Quality Management Systems 7
S Design and Development - Review vs. Verification vs. Validation Design and Development of Products and Processes 15
U Medical Device Design Review Records Requirements Design and Development of Products and Processes 16
kedarg6500 Manufacturing Process Design and Development Review ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 11
S Checklist for RA and QA Review of DVT (design verification test) for Software Other US Medical Device Regulations 2
R Who should document the Design Review Meeting and Design History File? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 8
T Design Review Checklist for an Electrical Engineering Consultancy Design and Development of Products and Processes 4
A QSR (820.30 part e) Design Review and Design Control Responsibilities 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 8
M Manufacturing Process Design and Development Review - TS 16949 Clause 7.3.4 IATF 16949 - Automotive Quality Systems Standard 12
S Design Review: Can I exclude Custom Products ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 2
Q ISO 9001:2008 - 7.3.7 - Review of Evaluation of Design and Development Changes ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 1
S Design Review Checklist Format Example wanted Design and Development of Products and Processes 16
Q Supplier Design Review Worksheet from a customer Supplier Quality Assurance and other Supplier Issues 1
M Design Review/Dimensional Analysis feasibility program or spreadsheet? Design and Development of Products and Processes 1
S Engineering Design Review minutes as Verification & Validation Records Design and Development of Products and Processes 7
J Design Review Participants - Medical Devices - Question Design and Development of Products and Processes 10
S Enhanced Design Review section - ISPE Commisioning and Qualification Guide Design and Development of Products and Processes 4
K Review of Design Dossier Design and Development of Products and Processes 1
B When is a Design Review required? - ISO9001:2000 Clause 7.3 Design and Development of Products and Processes 7
R Medical Device Product Requirements Document (PRD) a "Design Review"? Design and Development of Products and Processes 4
M Document Review Audit Findings - Design and Process Approach Design and Development of Products and Processes 2
P What results of a design review are documented in a DHF? Design and Development of Products and Processes 9
J DRBFM (Design Review Based on Failure Mode) - Toyota method Design and Development of Products and Processes 46
1 Design Review Process - Need a step by step methodology Design and Development of Products and Processes 4
H Design and Development Review 7.3.4 - Planned intervals for outputs and validation Design and Development of Products and Processes 3
Y ISO 9001 Design & Development - 7.3.4 Review, 7.3.5 Verify, 7.3.6 Validate Design and Development of Products and Processes 30
B Design - Simple System - ISO 9001 Clause 7.3 - Review vs. Verification vs. Validation Design and Development of Products and Processes 12
Z Reliability and Maintainability Design Review Guidelines Design and Development of Products and Processes 0
Z Appropriate Content for Design Review Documents Design and Development of Products and Processes 6
K Design Review Checklists Design and Development of Products and Processes 1
A Design Review Documentation Design and Development of Products and Processes 2
T Design Traceability - Labelling / Instructions for Use ISO 13485:2016 - Medical Device Quality Management Systems 5
B How to exclude empty rows in full factorial design analysis? Using Minitab Software 0
M Handling design changes with use-as-is inventory disposition Quality Manager and Management Related Issues 6
M Design Control - Management of Electronic CAD files Design and Development of Products and Processes 11
S Examples of FDA acceptable Software Design Specification (SDS) Medical Device and FDA Regulations and Standards News 6
A Design Change/ECO Related Question 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1

Similar threads

Top Bottom