Faculty of Engineering and Environment KF7011 System Analysis and Design with UML Assignment: Design Enhancing the current Quality Control processes of Newcastle Specials to improve their data integrity and efficiency. Module: KF7011 Systems Analysis and Design with UML Module tutor: Honglei Li Group 04: Joel Pearson (w17005730)Hugh Woodford (v090258963)Ismael J. Gomez (w20051520)Akramul I. Fahim (w19052798) Word Count: 4271 Executive Summary EXECUTIVE SUMMARY Newcastle Specials Quality Control unit is a quality control and assurance department operating for Newcastle Specials under Newcastle Hospitals business arm. Its main job is to be responsible for the testing and release of pharmaceutical products coming from the production unit. The current worksheet, paper-based system is a step-by-step process where a product is received into lab, a note is made that the product (along with its batch number) is awaiting testing, then when staff are available, they will print a worksheet for that specific product and carry out testing. Test results are recorded onto the worksheet, and if errors occur then a QCNC (Quality Control Non-Compliance) is generated and investigated. Upon conclusion or if the worksheet is completed without error, it goes to final approval and product release, generating a certificate of analysis. The products are then labelled as released and are then ready for dispatch. The worksheets are then archived for later access if required. The current process is prone to a high volume of input and technical errors that must be identified by a senior member of staff before data entry. There is also an issue with recording and storing test data for certain equipment that has no such internal or external mechanism. The proposed system looks at automating this process through the use of digital worksheets than can be checked automatically before data entry takes place. This system will also benefit from the faster release of products, cut down costs of printing and storage. The creation of a live digital system will also allow for potential multiple user views, meaning that other departments such as the stores dispatch staff may view the progress of any given item that is in process. The live QC test record system has been designed to improve the data integrity and efficiency of Newcastle Specials Quality Control (QC) processes by streamlining dataflow, providing authentication for employees and digitalizing the overall product testing process. This document outlines the planning and analysis phase of design which involves functional, structural and behavioural modelling. CONTENTS Executive Summary 2 1.0 System Request 5 2.0 Feasibility Analysis 6 2.1 Technical Feasibility 6 2.2 Economic Feasibility 7 2.3 Organizational Feasibility: If we build it, will they come? 7 2.4 Cost Benefit Analysis 9 3.0 Requirements Definition 11 3.1 Functional Requirements 11 3.2 Non-functional requirements 12 4.0 Functional Modelling 13 4.1 Use Case Descriptions 13 4.1.1 Current System (as is) 13 4.1.2 Intended System (to be) 19 4.2 Use Case Diagram 24 4.3 Activity Diagrams 25 4.3.1 Product Receival 25 4.3.2 Product Testing 26 4.3.3 QCNC Generation 27 4.3.4 Approval of record data 28 5.0 Structural Modelling 29 5.1 Class Responsibility Collaborator (CRC) Cards 29 5.2 Class Diagram 34 5.3 Object Diagram 36 6.0 Behavioural Modelling 37 6.1 Sequence Diagrams 37 6.1.1 Product Receival 37 6.1.2 Product Testing 38 6.1.3 QCNC Generation 38 6.1.4 Approval of Record Data and Product Release 39 6.2 Communication Diagrams 40 6.2.1 Product Receival 40 6.2.2 Product Testing 40 6.2.3 QCNC Generation 40 6.2.4 Approval of Record Data 41 6.2.5 Product Release 41 6.3 Behavioural State Machine 42 6.3.1 Product Receival 42 6.3.2 Product Testing & QCNC 43 6.3.3 Approval of Record Data 44 6.3.4 Product Release 45 6.4 CRUDE Matrix 46 7.0 Group Report 47 References 49 A. Client Contact 50 A.1 Interview Transcript 50 A.2 Follow up email 52 B. Code of Conduct 53 C. Meeting Minutes 57 C.1 Meeting 01 57 System Request Project Name: Enhancing the current Quality Control processes of Newcastle Specials to improve their data integrity and efficiency.Project Sponsor: Name: Adam Walker Department: Quality Control Organization: Newcastle Specials (Newcastle Hospital RVI)Business Need: A data integrity system fit for purpose. Certain processes of the current system are not immediately recorded onto an electronic system. Furthermore, the MHRA (Medicines and Healthcare products Regulation Agency) would prefer a system that would allow data to be immediately recorded and that cannot be changed or tampered with at a later date. Produce a live certification system for products for prompt release. The current system would highly benefit from a live certification system in order to release products without delay. Increase efficiency of the QC processes. The existing system needs a faster, more efficient and more reliable QC process overall.Business Value: Tangible: A more accessible system for all staff members. Time saving due to reduced needs for communication between departments. Greater efficiency, as the database checks should become easier and quicker to complete for senior staff members. Better product overview, system will allow a user to see the journey of the product.Intangible: Greater system security and greater compliance with MHRA requirements. Provides staff with additional tools and an easier way to overview products and see potential issues to facilitate earlier product release. They would feel more comfortable and satisfied at their workstations. Potential improvement of customer communication.Special Issues or Constraints: There is a need to work around current IT systems in place. This may limit the scope or scale of the work. Securing user authentication data. Can the current database system be transposed into the new system? Is there potential to reconstitute the current QCNC (quality control non-compliance) system into the new system? Feasibility AnalysisTechnical FeasibilityFamiliarity with business function There are several systems at play in the current QC process. Refining these systems into a conciliated overarching system should be possible given the current system functions. There may be limits due to the networking and various departments involved. The person/team that is building the system will be able to use this consultancy as instructions to carry out the work. However, a small degree of knowledge and context will need to be known in order to fully understand the instructions and build the system effectively. Familiarity with the technology Few computer machines in the lab. Possibility of adding more technological features in order to implement the system. The system implementation will require knowledge of databases and how to implement them, along with networking knowledge. The intended system will need to make use tablet technology in order to operate from within the lab. This will provide employees with a portable device that can be used around the lab to record test results digitally. Therefore, there will be a small degree of training to get employees familiar with the new system.The project will involve deploying the system on a cloud-based server; therefore, some degree of knowledge and experience will be required for both implementation and maintenance. Project Size and Scope The scope of the project will be initially limited to improving the current QC processes. There may be the opportunity to add more layers to the system which will be reviewed as the project proceeds and further meetings with the project sponsor. The client has requested a system that is fit for purpose. For example, the client has stated that certain test procedures do not fully comply with data integrity requirements, as they have no means to document evidence of those particular tests. We would have to evaluate the different options to provide a workable solution. This is expanded on in the requirements definition section.The client has requested to evaluate the viability of a live certification system, which would involve the partial generation of a certificate of analysis as the testing steps are carried out. This would mean staff (such as business sales or stores dispatch staff) could view where a product is along the release process. However, because of the way the current system works, information is only passed to a certificate of analysis once all the data is in the database. For this to work, information would need to be passed contemporaneously once recorded. Therefore, our system provides a compromise where the user will be able to view a worksheet in progress. This can be provided by authentication and user views and permissions. Economic FeasibilityTangible Benefits Earlier product release, faster customer service. Less printing of paper reports and certificates. Intangible Benefits Time saved by lessening the burden on inter-departmental communication. Scalable solution that will be future proof. Increased security lessens threat of losing or corrupting data, meaning less external support required. Compliance with MHRA guidelines and greater data integrity, a system fit for purpose (Greater protection against penalties in the future).Time saved for individual scientists, less time spent checking and transcribing information to the database. A direct increase in the amount of available man hours per week for the lab. Organizational Feasibility: If we build it, will they come? Table 2.1: Organizational feasibility table. Role Techniques for Improvement Champion A champion: Adam Walker (Quality Controller for Newcastle Hospitals) Initiate the project. Promote the project. Provide information and resources. Allocate time to project (meeting with consultancy team). Present the aims and objectives of the proposed system as well as the expected benefits it will provide. Demonstrate a prototype of the developed system in order to show its value. Senior Management Head manager of production unit and Business manager: Know the potential use of the to-be system. Meet the economic needs for the completion of the project. Break down and market the benefits of the project with a presentation and memos. System Users Daily users of the system; Quality Control Scientists, Lab Manager, Senior Operatives. Provide feedback on produced designs and prototypes in order to make improvements. Liaise with daily users to address needs and concerns. Ask if daily users have any features or suggestions that they would like to be implemented that would facilitate ease of use or improve the service. Other Stakeholders Suppliers. Programmers in charge of implementing the system. Potential business partners. Sellers of the system to other interested institutions. A clear set of aims and a design model that is intuitive and simple to follow. The stipulations of the design process must be clearly shown, and any potential issues or ambiguity must be addressed preemptively. Potential commercial benefits, the system could be sold or licensed. Cost Benefit Analysis Our client clearly states that the main concern of the proposed system is a change to regulatory compliance and data integrity systems as shown in Appendix A.1. Overall, the value of this project is in increased regulatory compliance rather than time savings our current system is not fit for purpose!. As such, there isnt a focus on significant cost saving but instead of making a more secure system. However, we have evaluated any potential savings that could be gained from reduced printing costs, along with potential man hours saved due to this new system. As we have not been able to acquire certain sensitive data, estimates of savings will be provided based upon speculated figures based upon a group members previous work experience (2 years at Senior Quality Operative) at the unit. Units: British Pounds (£) Table 2.2: Cost benefit analysis table for the next 5 years. 20212022202320242025TotalBenefitsPrint savings5005055105155202,550Man hours saved3,6943,7303,7683805384318,840Total Benefits4,1944,2354,2784,3204,36321,390Development CostsConsultation2.0002,000Installation30,00030,000Hardware4.0004.000Staff training100100Total Development Costs36,10036,100Operational CostsMaintenance7507507507503,000Cloud Server1,2001,2201,2401,2604,920Total Operational Costs1,9501,9701,9902,0107,920Total Costs31,906-2,285-2,308-2,330-2,35322,630 Break-even point = 13 years (2034) Break-even point is calculated by a compounded cost saving based upon an increase of 1% of product output, saving roughly £2200-2600 (trending towards the latter) every year. As savings are in man-hours and some printing costs, this is contingent upon the maximum level of product output being achieved by the unit. Calculation for money in man-hours saved per year through hours saved by scientists: Hours worked per year 37.5×52 = 1950hrs/y Yearly wage = 34,638 34,638/1950 = £17.76 8 hours p/w x 17.76 = 142.08 p/w New estimate time 4 hours = £72.04 £7,388.16 current cost p/y £3,694.08 new cost p/y Savings of £3,694.08 p/y in man hours Requirements DefinitionFunctional RequirementsThe system must have an approve option. After a user has recorded test results, a senior member of staff must have an option to approve the results (for after they have reviewed the results) so that they can be passed to the database. The system must implement a method where QC technicians can record their test results digitally. It is important that the results are in a digital format before being passed to a senior member of staff for review. The system must have a method of catching and highlighting errors to be further confirmed. It will give the user an option to discern between a technical error and an input error. Technical error (QCNC):An error that was made by the user (e.g., wrong testing, over confidence, precision errors, etc ) and should be corrected by a senior member. This will lead to the generation of a QCNC. Input error:An error that where the user, inputs the incorrect value. This could be simply (e.g. writing the value 97 instead of 98 for a test result). The system must have a method that allows the users to access different types of product QC tests. Newcastle Specials handle many different types of products and each has a unique set of tests to be carried out on them. To improve efficiency for the user, the QC technicians must have easy access to all the different QC tests for each product. The system must be able to be used by multiple users at the same time. It will need to be used by multiple technicians in the lab. The system must provide the user (internal or external customers) with an option to print a released Certificate of Analysis after the results have been approved by a Senior QC Scientist or Lab Manager. This was a direct requirement from the sponsor. The system must have a user authentication function. This is to improve the data integrity of the system so that multiple users cant alter the same documents and to ensure that only senior members can approve QC results. The system must provide users with a function to add and customize their own templates (worksheets). This function will provide users with the tools to create and customize their own templates for future scalability and added functionality. The system should have a live certification that is viewable in-organization. This live certificate will show complete and incomplete data so that another user (e.g., business office) can view the current state of a product and where it is in the pipeline. The system should prompt users to change passwords every 3-months. This function will make the system more secure by having users consistently changing their password. The system could have a system that highlights out of trends and potential problems. Out of trends are those pr
oducts that give out of trend results, e.g., a product typically ranges from 97-102% gives a result of 104%, this will be highlighted, and a record kept. Products with common out of trends could give user prompts that highlights specific parts of the process that frequently cause problems, with the user having to acknowledge this before moving on. The system could contain all of Newcastle Specials SOPs for digitalized easy access. A nice addition for the system would be to have all the SOPs accessible by the QC technicians for easy referral. Non-functional requirementsThe system must be deployed on the cloud. This gives the system a better level of scalability. The system must be accessible from multiple locations. If a staff member is at home or not in the lab because of any reason, it would let them access the system. The system must have a saving/auto-saving system. It would provide data-integrity and would make sure that data wont get lost if you have a break and come back to your task after some time. The system should make use of a username and password to authenticate a user login. This is opposed to other authentication methods such as a pin-code or two-factor authentication techniques. The system could lockdata that is under review. It is viewable in-house but cannot be edited except by a senior manager or the person who originally inputted the data. System should automatically logout a user after 30 minutes of inactivity. To increase security and data integrity, after 30 minutes of inactivity a user will be logged out to ensure that the system cannot be accessed by others. Functional ModellingUse Case Descriptions The use-case descriptions below provide an overview of the business processes involved in the developing system (Dennis, Wixom and Tegarden, 2015, pp. 146; Bolloju and Sun, 2012, pp. 2182). The approach for this project involved developing use-case descriptions for the current processes of Newcastle Specials (section 4.1.1) to identify areas that could be improved. Then use-case descriptions of the intended system (section 4.1.2) were developed with the enhancements in mind. Using this approach, the group was able to remove a use-case altogether from the current processes which will lead to a more efficient system with a more streamlined flow of data. Current System (as is) Use-cases describing the current system/processes of Newcastle Specials. Use-case Name: Product receivalID: 0Importance Level: MediumPrimary Actor(s): Production staff, QC staffUse-case Type: ExtensionStakeholders and Interests: QC staff, Senior Production staffBrief Description: This use-case describes the process of how a product is received by the QC staff to then be tested.Trigger: The product is received through QC hatch from the production unit. Type: InternalRelationships: Association: Product testing Include: Extend: Generalization:Normal Flow of Events: A sample of the original product produced by the Production Staff is passed through to QC for the testing to be carried out. Product name is recorded onto a white board and the type of testing it needs. Product is stored in the correct conditions, awaiting testing (in quarantine).Sub-Flows: N/AAlternate/Exceptional Flows: N/A Use-case Name: Product TestingID: 1Importance Level: HighPrimary Actor(s): Senior QC Scientist, Senior QC OperativeUse-case Type: EssentialStakeholders and Interests: QC Staff, Business Staff, CustomerBrief Description: This use-case describes how standard testing is carried out following a QC worksheet.Trigger: Product is received through QC hatch from the production unit. Type: ExternalRelationships: Association: Product Manufacture, Approving record data Include: Extend: QCNC Generalisation: QC product testingNormal Flow of Events: Product is selected from white board Relevant QC worksheet printed Testing carried out on product Results recorded on QC worksheet Product paperwork put back into tray for review by senior staff memberSub-Flows: N/AAlternate/Exceptional Flows: When there is an error in the testing process or a result that is outside of tolerance, then a QCNC must be generated (after event 8) Use-case Name: QCNC generationID: 3Importance Level: MediumPrimary Actor(s): QC Operative, QC ScientistsUse-case Type: ExtensionStakeholders and Interests: QC StaffBrief Description: When an error or adverse event occurs, then a record of events must be made, and a root cause identified.Trigger: Adverse event, error or result obtained from testing out spec, spread, or limit. Type: ExtensionRelationships: Association: Include: Product Testing, Approval of record data Extend: Generalisation:Normal Flow of Events: Upon trigger, a QCNC code is generated for the product batch. This is recorded on EXCEL worksheet. All relevant SOPs for recording the QCNC investigative process are printed. A senior member of QC staff will lead the QCNC questioning phase to assess whether there were any procedural errors on behalf of the QC staff carrying out the original testing. If procedural error was found, then go to sub flows. Investigate whether there was a potential error in production, or errors due to faulty equipment. Print off new worksheet and append to original batch documentation. If no immediate root cause can be identified, then repeat tests (2) to ensure accuracy. Complete paperwork concluding investigation, identifying root cause, any changes required in process etc. Manager signs off paperwork closing QCNC investigation.Sub-Flows: S-1: If procedural error, repeat testing and record new results.Alternate/Exceptional Flows: N/A Use-case Name: Approval of record dataID: 4Importance Level: HighPrimary Actor: Senior QC ScientistUse-case Type: EssentialStakeholders and Interests: QC scientists wants to ensure that the recorded data is correct in order for it to be approved. QC senior scientistsBrief Description: This use-case describes the processes carried out for approving the recorded test results of a product.Trigger: Once the initial testing is competed, and data has been recorded by previous process a Senior QC staff member takes results from the tray for review. Type: InternalRelationships: Association: Product Testing, Data input Include: Extend: QCNC Generalization: QC product testingNormal Flow of Events: Senior QC staff member retrieves worksheet from completed tray. The results are reviewed and compared against known tolerances (out of limits) and to identify out of trends. The Senior QC staff member will also review all mathematical processes, weights measured etc. to make sure that everything is recorded correctly.Sub-Flows: S-1.1: No out of limits or out of trends are identified. S-1.2: The testing can be approved.S-2.1: An issue is identified. S-2.2: A QCNC is generated.Alternate/Exceptional Flows: A product gets approved that shouldnt have been approved (The Senior QC member just made a mistake). A product recall is generated. Use-case Name: Data inputID: 5Importance Level: HighPrimary Actor: Senior QC ScientistUse-case Type: EssentialStakeholders and Interests: Senior QC staff wants to make sure that the approved test results are successfully stored in the product database.Brief Description: This use-case describes how the approved recorded test results are inputted into the product database.Trigger: Once a worksheet has been approved and the document is placed in the approved tray. Type: InternalRelationships: Association: Approving record data, product release Include: Extend: Generalization: QC product testingNormal Flow of Events: A senior staff member retrieves an approved worksheet from its corresponding tray. The data is then manually inputted into the product database (simple data entry).Sub-Flows: N/AAlternate/Exceptional Flows: An input error is made when entering the data into a database. The error can be noticed on the final certificate. Use-case Name: Product releaseID: 6Importance Level: HighPrimary Actor: Senior QC ScientistUse-case Type: Detail, EssentialStakeholders and Interests: QC Staff wants the product to be successfully releasedTrigger: The product has undergone all relevant testing and been approved. Type: InternalRelationships: Association: Data input, Business Sale Include: Extend: Generalization: QC product testingNormal Flow of Events: The product certificate of analysis is produced using the database tool Final sign-off of paperwork to confirm that product is ready for release The Senior QC staff member will apply released by QC to the relevant product.Sub-Flows: N/AAlternate/Exceptional Flows: N/A Intended System (to be) Use-cases describing the intended system/processes of Newcastle Specials. Use-case Name: Product receivalID: 0Importance Level: MediumPrimary Actor(s): Production staff, QC staffUse-case Type: ExtensionStakeholders and Interests: QC staff, Senior Production staffBrief Description: This use-case describes the process of how a product is received by the QC staff to then be tested.Trigger: The product is received through QC hatch from the production unit. Type: InternalRelationships: Association: Product testing Include: Extend: Generalization:Normal Flow of Events: A sample of the original product produced by the Production Staff is passed through to QC for the testing to be carried out. Open a new product entry using the live system and add name and test required. Product is stored in quarantine until testing is requiredSub-Flows: N/AAlternate/Exceptional Flows: N/A Use-case Name: Product TestingID: 1Importance Level: HighPrimary Actor(s): QC Operatives, QC ScientistsUse-case Type: EssentialStakeholders and Interests: QC StaffBrief Description: This use-case describes how a product is tested.Trigger: A product that has been recorded onto the system is ready for testing Type: InternalRelationships: Association: Product receival, Approval of record data Include: Extend: QCNC generation Generalisation:Normal Flow of Events: QC Staff sign into system. Digital Worksheet produced. Tests carried out according to SOP standards. Results recorded via the live system. Upon contemporaneous check by 2nd member of QC staff, results recorded onto live system. Confirm function is used to after completion of testing.Sub-Flows: S-1: Product retrieved from quarantine.S-2: Where appropriate (e.g. using non-networked equipment such as pH meter) take photo of result and attach to worksheetAlternate/Exceptional Flows: When there is an error in the testing process or a result that is outside of tolerance, then a QCNC must be generated (after event 4) Use-case Name: QCNC generationID: 2Importance Level: MediumPrimary Actor(s): QC Operative, QC ScientistsUse-case Type: ExtensionStakeholders and Interests: QC StaffBrief Description: When an error or adverse event occurs, then a record of events must be made, and a root cause identified.Trigger: Adverse event, error or result obtained from testing out spec, spread, or limit. Type: ExtensionRelationships: Association: Include: Product Testing, Approval of record data Extend: Generalisation:Normal Flow of Events: Upon trigger, a QCNC code is generated for the product batch. (This should be automatically created in the same database as the product database?) All relevant SOPs for recording the QCNC investigative process are printed. A senior member of QC staff will lead the QCNC questioning phase to assess whether there were any procedural errors on behalf of the QC staff carrying out the original testing. If procedural error was found, then go to sub flows. Investigate whether there was a potential error in production, or errors due to faulty equipment. Complete paperwork concluding investigation, identifying root cause, any changes required in process etc. Close out QCNC investigation on database. Input post-retesting results onto live system with manager/senior approval.Sub-Flows: S-1: If procedural error, repeat testing and record new resultsAlternate/Exceptional Flows: N/A Use-case Name: Approval of record dataID: 4Importance Level: HighPrimary Actor(s): Senior QC scientistUse-case Type: EssentialStakeholders and Interests: QC scientists, Senior QC scientistsBrief Description: This use-case describes the processes carried out in order to approve the recorded test results of a specific product.Trigger: Once the testing phases are complete, a senior QC scientist oversees the recorded data before it is registered in the system. Type: InternalRelationships: Association: Product testing, QCNC generation, Data input Include: Extend: QCNC Generalisation: QC product testingNormal Flow of Events: A Senior QC scientist logs into the system via the authentication function. System flags and highlights any out of bounds. The recorded results are compared against known tolerances (out of limits) and out of trends. Mathematical processes, measured weights, etc. Are reviewed to verify everything is correct. The Senior QC Scientist indicates the registered data is reviewed and correct using the approve function. The Senior QC scientists confirms submission of document data by clicking approve. This data is uploaded to the database upon approval (via a simple SQL insert statement).Sub-Flows: S-1.1: No out of limits or out of trends are identified. S-1.2: The testing is approved in the IT system.S-2.1: An issue is identified. S-2.2: A QCNC is generated.Alternate/Exceptional Flows: A product that should not be approved gets approved by the Senior QC scientist by mistake. A product recall is generated. If an error is spotted, or there is a result that is outside of tolerance, then a QCNC must be generated. Use-case Name: Product releaseID: 6Importance Level: HighPrimary Actor: Senior QC StaffUse-case Type: Detail, essentialStakeholders and Interests: QC Staff wants the product to be successfully releasedTrigger: Data input use-case. Type: InternalRelationships: Association: Data input Include: Extend: Generalization: QC product testingNormal Flow of Events: Sign off batch confirming release Manually label approved product with pass stickers. A certificate of analysis is generatedSub-Flows: N/AAlternate/Exceptional Flows: N/A Use Case Diagram The use-case diagram produced represents the actors, use-cases and the relationships between them. It helps show how the system interacts with the user and indicates the actors activity with the system. When comparing the use-cases for the current processes and the intended system, it is clear that the new system will be more efficient which is indicated through the fewer number of use-cases of the intended system. By cutting out the data input use-case, the intended system will be more streamlined and have a better flow of data. The system boundary has been defined excluding the database from our current system design. It is important that realistic goals can be achieved within the scope of this project. Consultation with the client (appendix A) made it clear that database management lies outside the control of the QC department, and as such designing a system that can work independently from the database system, whilst still considering its future potential incorporation is the best course of action. Figure 4.1: Use Case Diagram. Activity Diagrams The activity diagrams below provide a visual representation of the use-cases developed previously (section 4.1.2). This represents the step-by-step processes of the system which indicates the workflows between use-cases. The main purpose of activity diagrams is to capture the dynamic behaviour of the system. The activity diagrams have been proposed and designed with regards to the current system so as not to change or overhaul any of the testing processes, but to simply provide a more efficient and secure platform to record test results. Moreover, the decision nodes for each activity diagram are essentially contingent upon errors occurring during the testing processes, whereby QCNCs are generated, and investigations carried out if required. If no errors occur, then the activity diagrams are straightforward with no branching. Product Receival Product Testing QCNC Generation Approval of record data Structural ModellingClass Responsibility Collaborator (CRC) Cards CRC cards are used to document the responsibi