Appendix C - A Template Of User Requirements Document
BEST PRACTICESFOR BUSINESS ANALYSTAPPENDIX CA TEMPLATE OFUSER REQUIREMENTS DOCUMENTWITH SAMPLE CONTENTS[G60c]Version: 1.0December 2016 The Government of the Hong Kong Special Administrative RegionThe contents of this document remain the property of the Office of the Government ChiefInformation Officer, and may not be reproduced in whole or in part without the expressedpermission of the Office of the Government Chief Information Officer.
Best Practices for Business AnalystAppendix CAmendment HistoryAmendment HistoryChangeNumberRevisionDescriptionPages AffectedRev.NumberDate
Best Practices for Business AnalystAppendix COverviewOVERVIEW(a)A user requirement is “what” must be delivered to provide value to business whensatisfied rather than “how” to deliver. A User Requirements Document (URD)describes what the proposed IT system looks like from a business perspective. Itis important as it helps gain agreement with stakeholders and provides afoundation to IT project team on what the system needs to do to satisfy thebusiness needs and user expectations, and provide input into the next phase of thedevelopment.(b)A URD normally consists of the following information:i)Introduction, e.g. purpose of the URD, project background, businessobjectives, project scope and objectives, etc.;ii) Identified Risks, Assumptions and Constraints;iii) Proposed System Overview, e.g. high-level system diagram or description andsystem user profile;iv) Future Business Process;v) Functional Requirements define the functions or features of a system that canbe utilised by a user to fulfil business operation (i.e. what the system shoulddo to provide business value when satisfied);vi) Non-Functional Requirements such as audit, control and security, globalbusiness rules, data requirements, usability requirements, service level targets,user volume and equipment requirements, data growth and retentionrequirements, etc. specify criteria of how the system can perform and maintainthese functions and features (i.e. how the system should work) from a businessperspective;vii) Implementation Considerations such as implementation strategy, rollout andtransition approach, data conversion, training approach, etc.viii)Appendices, e.g. Future Business Process Diagrams, Data Requirements,Reference Documents, Glossary of Terms, etc.(c)A sample template of URD with sample content is provided below. B/Ds shouldadopt the sample template flexibly and make changes as necessary to suit projectneeds.
Best Practices for Business AnalystAppendix C(d)OverviewNotes for using the template are written in “italic” text enclosed in pointedbrackets “ ”, while sample contents are written in “bold italic” and can bereplaced by project-specific information or removed to suit specific project needs.After all changes are made, all notes should be removed and font of all “bold italic”text should be changed to normal.
Best Practices for Business AnalystAppendix COverviewHINTS AND TIPS(a) The requirements should be accurate, clear, complete, verifiable, consistent, understandableand concise.(b) Technical solutions or elements (e.g. data architecture, application architecture, systemarchitecture, technical infrastructure, etc.) should be avoided. Such solutions are proposedby IT staff during system design.(c) Acceptance criteria define the boundaries for the functional requirements and they should bewritten in a clear and concise manner.(d) If Agile software development method is used, only high-level requirements will beproduced in the SA&D stage. Requirements should be written in layman’s terms which arecalled “User Stories”.Please refer to the “Practice Guide for Agile Software1Development ” for more information about Agile.1 “Practice Guide for Agile Software Development” can be found ology/system development/agile software development.htm.
With Sample ContentUSER REQUIREMENTSDOCUMENTFORINVENTORY MANAGEMENTSYSTEMOFDDD DEPARTMENTVersion: 0.1MMM YYYY The Government of the Hong Kong Special Administrative RegionThe contents of this document remain the property of and may not bereproduced in whole or in part without the express permission of theGovernment of the HKSAR.
With Sample ContentUser Requirements DocumentProject IdentificationProject IdentificationProject Name:e.g. Implementation of Date:Inventory ManagementSystem for DDDDepartmentProject Owner:e.g. Mr. AAAPost/Rank:BusinessAnalyst:Post/Rank:e.g. Head(ITMU)dd/mm/yyyye.g. Mr. SEOe.g.SEO(Team)1Revision HistoryRevision No.Revision noRevision Datedd/mm/yyyyPages/Sections RevisedRevised pages and sectionsRemarksDistribution ListNameMr. AAPost/RankSSM(ITMU)1B/DDDD DepartmentDatedd/mm/yyyyMr. BBSM(ITMU)11DDD Departmentdd/mm/yyyyMr. CCSSO(SU)1DDD Departmentdd/mm/yyyyMr. GGSM(ITMU)31DDD Departmentdd/mm/yyyyMs. FFEO(DIV)11DDD Departmentdd/mm/yyyy
With Sample ContentUser Requirements DocumentTable of ContentsTable of Contents1INTRODUCTION. 11.11.21.31.41.52Purpose. 1Project Background . 1Business Objectives . 2Project Scope . 2Project Objectives . 3IDENTIFIED RISKS, ASSUMPTIONS AND CONSTRAINTS . 42.1 Identified Risks . 42.2 Assumptions. 52.3 Constraints . 53PROPOSED SYSTEM OVERVIEW. 63.1 Description of Proposed Inventory Management System . 63.2 System User Profile . 74FUTURE BUSINESS PROCESS . 84.1 List of Future Business Process . 84.2 BP001-Creation of New Inventory Record. 94.3 BP002-Update of Inventory Record . 145FUNCTIONAL REQUIREMENTS . 155.1 List of Functional Requirements . 155.2 REQ-CRE-000 Creation of New Inventory Record . 166NON-FUNCTIONAL REQUIREMENTS. 196.16.26.36.46.5List of Non-Functional Requirements . 19Audit, Control & Security Requirements. 20Global Business Rules Requirements . 24Data Requirements . 25Usability Requirements . 286.6 Service Level Targets . 296.7 Data Growth and Retention Requirements . 316.8 Number of Users & IT Equipment Requirement . 317SYSTEM IMPLEMENTATION CONSIDERATION. 33APPENDIX . 34
With Sample ContentUser Requirements Document1INTRODUCTION1.1PURPOSEIntroduction of URD This section describes the purpose of the document. e.g. This document defines the user requirements for the new computerised InventoryManagement System (IMS) for DDD Department. The information stated in thisdocument will be used as the basis for subsequent development activities includingdesign, implementation, testing and post-implementation review.1.2PROJECT BACKGROUND This section provides background information about the project to facilitate reader’sunderstanding why the project is initiated and reasons for change. Information mayinclude name of B/D involved, sections or teams, major current problems, issues,challenges, etc. e.g. Currently, there is no IT system supporting the inventory management in DDDDepartment. The Supplies Section of the Administration Division in the departmentis responsible for managing the stores, inventory and procurement matters for theentire department. The Section has about xx staff and is headed by a SeniorSupplies Officer (SSO). All inventory records are manually processed andmaintained by the staff of the Supplies Section under the Administrative Division.There are about 29,999 inventory items stored in paper folders and some are alsosaved in spreadsheets or other word document formats for easy retrieval.The department is looking for a computerised system for storing inventory records,and facilitating inventory management and control activities such as annual physicalinventory checks, inventory transfer, write-off of lost inventory items and disposal ofsurplus stores.1
With Sample ContentUser Requirements Document1.3Introduction of URDBUSINESS OBJECTIVES This section briefly describes the high-level business objectives that the users need toachieve i.e. the expected business outcomes of the project. The performance of thedeveloped system will be assessed whether it can meet the business objectives or notduring the Post Implementation phase of the System Development Life Cycle (SDLC).These objectives should align with those stated in the Business Case Document. e.g. The high-level business objectives for the project are to:1.2.3.4.5.1.4facilitate the inventory management (easier recording, monitoring and control);reduce occurrence of discrepancies between inventory records and actualquantities in hand;enhance planning for future requisition of inventory items (handy updatedbalance information, analysis and report summaries);allow timely arrangement of maintenance programme of inventory items; andshorten the time for annual inventory checking exercise.PROJECT SCOPE This section provides a high-level description of what the project/the new IT systemwill do. This may include a list of major target functions/work, interfaces with othersystems, feasibility study, training, data conversion, set up of new sites/offices, etc. e.g. The new IMS aims to automate the management of inventory covering the fulllife span from stock-in until disposal or write-off. The system is required tofacilitate inventory management and control activities i.e. the arrangement ofmaintenance services, annual inventory checks, write-off of lost inventory items anddisposal of surplus stores.The project shall provide System Analysis & Design (SA&D) and SystemImplementation as well as Training and Data conversion services for the IMS of theDDD Department. The major functions to be provided by the system are listedbelow:a) Creation, updating, deletion and enquiry of inventory items;b) Transfer of inventory items;2
With Sample ContentUser Requirements DocumentIntroduction of URDc) Disposal of inventory items;d)e)f)g)h)1.5Trade-in of inventory items;Write off/Replacement of loss inventory items;Annual Physical Inventory Check;Reports for inventory transactions and status of inventory items; andInterfaces with other related IT system including Software Asset ManagementSystem for software licences and e-Procurement System for maintenance services,purchase orders and invoices.PROJECT OBJECTIVESe.g. The project objectives are to:a) make use of ICT facilities to automate the current manual work processes forinventory processing;b) improve the efficiency of daily inventory processing and re-allocate the savedstaff resources to handle other more urgent procurement matters;c) strengthen the control and monitoring of loss or surplus of inventory items;d) shorten the processing time and effort for conducting annual physical inventorycheck;e) provide online facilities for enquiry and report for the balance and status off)inventory items, e.g. distribution of software and processing status of items to bedisposed; andprovide online data for use by other related systems, e.g. software assetmanagement system, procurement of maintenance services, etc.3
With Sample ContentUser Requirements Document2Identified Risks, Assumptions and ConstraintsIDENTIFIED RISKS, ASSUMPTIONS ANDCONSTRAINTSe.g. The followings are the identified risks, assumptions and constraints related torequirements collected at this stage from the business users and/or the stakeholdersinvolved.2.1IDENTIFIED RISKSe.g. The list of identified risks for the project is shown below:Table 1 - Identified Risks Related to RequirementsNo.Risk Description1.Many old papersupportingdocuments orforms may beunclear forreading, or beeasily damagedduring scanningLow2.Unable toextract relatedprocurementinformationfrom the new eProcurementSystem if it is notlaunched bymmm/yyyy w/ Rare) (Cost, Schedule,Scope, Qualityor Others) RiskRatingPossibleResolutions &MitigationRiskOwnerQuality ofsupportingdocuments areaffectedLowSuppliesSectionProjectschedule willbe affected.LowUse flatbedscanning forfragiledocuments;define a cut-offtime for not toscan alldocuments, e.g.scan documentsonly up to lastthree years.Closecollaborationwith eProcurementSystem projectteam, andprepare forworkaroundsolution SuppliesSection 4
With Sample ContentUser Requirements Document2.2Identified Risks, Assumptions and ConstraintsASSUMPTIONS Assumptions are factors that can affect the requirements, and are believed to be trueduring the entire SDLC of the project. Any changes to the assumptions may affect theproject outcomes, e.g. resources, schedule, cost and benefits, etc. e.g. The identified assumptions are listed below:1. The Inventory Record Administrators will proactively notify the SuppliesSection for any inventory transactions for his/her section as soon as possible.2. There will be no changes in postings of key stakeholders during the SA&D phase.If there are changes, requirements are still able to be provided by the successorsor other members in the stakeholder groups.3.4.2.3Direct migration approach will be used to implement the system. No parallelrun will be performed.Only supporting documents for the items procured in last xx years will bescanned into the system for use.CONSTRAINTS Constraints are factors or requirements imposed by the business or other systems thatwill limit the scope and functionality of the proposed IT system, e.g. Government law,policy and regulations, technical limitations, resources, expertise of project teammembers, etc. Constraints may also limit the available options for the system. e.g. The identified constraints are listed below:1. The system shall comply with the DDD Circular No. 99/2014 on xxxxx, and theGuidelines on XXX published by OGCIO.2. The system must be run in the Government/departmental XXX platform tofacilitate interfaces with other existing systems in the department.3. The setup of an interface for sending maintenance data about computer itemsin the new system to the e-Procurement system will depend on the availability ofthe new e-Procurement System which will be launched in MMM YYYY.4. The system cannot enforce all out posting or leaving officers from thedepartment to submit an inventory transfer record for all inventory items underhis purview before leaving DDD Department. It relies on the InventoryAdministrator to perform this afterwards as the inventory receiver may not be5.known at the time of leaving. 5
With Sample ContentUser Requirements Document3Proposed System OverviewPROPOSED SYSTEM OVERVIEW This section provides a brief description about the proposed IT system to be developedby presenting a high-level conceptual model of the system and showing a system userprofile about the users of the proposed IT system that will be referred to in followingsections. 3.1DESCRIPTION OF PROPOSED INVENTORYMANAGEMENT SYSTEM The following context diagram (or other diagrams) can be used to provide users witha high-level overview about the proposed system including the system boundaries,external and internal users/systems that interact with the system and the majorrequirements that they have defined in this document. Alternatively, BA may providean overview of the proposed IT system in the form of text description. e.g. A sample of Context Diagram for the project is shown below:Figure 1 - Context Diagram of Inventory Management System6
With Sample ContentUser Requirements Document3.2Proposed System OverviewSYSTEM USER PROFILE The following provides a table of external and internal users of the proposed ITsystem. Each user will have a role in the proposed IT system as shown in the circlesin the above context diagram, and mapped to a user type in the table below. e.g. A sample of System User Profile for the project is shown below:Table 2 - System User ProfileNo.User LD SuppliesResponsibilitiesBranch/ Division/ StaffSection/ UnitPost/RankStakeholderGroupResponsible foroverseeing theentire system’soperation and useResponsible forapproval, reviewand control of thedaily operation andupdate of inventoryrecordsResponsible forinventorytransactions andrecords updateResponsible forinventory items ofthe section underhis/her custodyAssist InventoryHolder to maintainup-to-dateinventory recordsResponsible forsystemadministration ofthe inventorysystemResponsible forapproval of tradein, write-off anddisposal ofinventory itemsSupplies SectionofAdministrativeDivisionSupplies tionSOSuppliesSectionSupplies SectionofAdministrativeDivisionXX SectionSSSuppliesSectionXX orequivalentranksSection HeadsXX SectionXX orequivalentranksSection UsersIT OperationsIT OfficerITMUDivision XX ofGLDDepartmentSuppliesOfficerGLD7
With Sample ContentUser Requirements Document4FUTURE BUSINESS PROCESS4.1LIST OF FUTURE BUSINESS PROCESSFuture Business Process The following table provides a list of future business process flows for the system. Table 3 - List of Future Business Processes for the Inventory ManagementSystemProcess IDBP-001Business Process TitleCreation of New Inventory RecordBP-002Update of Selected Inventory RecordBP-003Transfer of InventoryBP-004Disposal of InventoryBP-005Trade-in of InventoryBP-006Write off/Replacement of loss InventoryBP-007Annual Inventory Taking Exercise8
With Sample ContentUser Requirements DocumentFuture Business Process4.2BP001-CREATION OF NEW INVENTORY RECORD4.2.1PROCESS DIAGRAMS FOR CREATION OF NEWINVENTORY RECORD(a)Use Case Diagram for Creation of New Inventory Record Use Case Diagram is used to show a business case by identifying theinvolved actors and related actions or tasks that the actor will participate, orby identifying the related external event that the system needs to respond.Use Cases can help to handle events & processes. Please refer to AppendixA-5.6 for more information about Use Cases. Figure 2 - Use Case Diagram - Creation of New Inventory Record9
With Sample ContentUser Requirements Document(b)Future Business ProcessProcess Flow Diagram for Creation of New Inventory Record For each use case diagram, flow diagrams are used to graphically depictthe sequence of operations or the movement of business processes. If thebusiness process is a complex one, it can be further broken down into subprocesses. 10
With Sample ContentUser Requirements DocumentFuture Business ProcessFigure 3 - Process Flowchart for Creation of New Inventory Record11
With Sample ContentUser Requirements Document4.2.2Future Business ProcessPROCESS DESCRIPTION FOR CREATION OF NEWINVENTORY RECORD The following provides text description for the future business process flow. Table 4 - Process Description for Creation of New Inventory RecordTaskNo.1ActorTask Name and Receive new items, certify invoiceNew items,invoiceGFxxxform, a copyof certifiedinvoiceGFxxx formSuitableItemCategoryCode(s)GFxxx form, POInventoryitemsrecordsScanned copy ofcertified invoicein PDFInventoryitemsrecordslinked withinvoice.Inventory itemsrecordsConfirmedcreation ofinventoryand fill in GFxxx.Inform the Inventory ControlAssistant of Supplies Section afterreceipt of newly purchased items forthe Section, fill in form GFxxx andpass a copy of certified invoice forsupporting.2InventoryControlAssistantSearch for existing suitable itemCategory Code & Item Number.If the Inventory Control Assistantcan find suitable Item CategoryCodes and Item Numbers for allitems, go to task 3.If not, Inventory Control Assistantwill go to create new Items CategoryCodes, and then return to continueTask 3.3InventoryControlAssistantInput the inventory itemsinformation.The system should perform validityand completeness check of inputinformation and validate it againstPO.4InventoryControlAssistantUpload the PDF file of the certifiedinvoice copy to the system, and linkthe inventory items under this recordto the invoice.5InventoryControlAssistantCheck if invoice amount HK 1M.If invoice amount HK 1M, seek12
With Sample ContentUser Requirements DocumentFuture Business Processitemsrecordsapproval from Inventory ControlManager. If invoice amount HK 1M, seek approval fromInventory Control Officer.6InventoryControlAssistantCreate new item record, send emailNew inventoryrecordnotification and print & distributebar code label.Bar codelabels,notificationemailsUpon approval, send emails to notifyInventory Record Administrator andInventory Holder and print anddistribute bar code labels toInventory Record Administrator forsticking on the items.Other informationReferences:1.SPRxxx Clauses of the Stores and Procurement Regulations2.DDD Internal Circular 9/9999 Record of Inventory Items issued ondd/mm/yyyy3. Sample documents including GFxxx, invoice and PO.4. Current inventory item list (in Excel form).Assumptions:1.It is assumed that any staff in a section who has initiated changes ininventory records of that section will proactively pass all requiredinformation to the Inventory Record Administrator of the Section, whoin turn coordinates with the Inventory Control Assistant for creation ofnew inventory records.2.Each inventory item is properly categorised and assigned with an itemnumber.Business Rules:3.No work-in-progress items will be recorded to the IMS.4.Each inventory item shall be linked with the corresponding invoice.1.Each inventory record will contain multiple inventory items that arecharged by one single invoice.2.The supplier’s invoice must be properly signed and certified beforesubmitted to the Inventory Record Administrator, who in turn will notifythe Inventory Control Assistant to create a new inventory record.3.If the total amount per invoice HK 1M, approval for the creation ofinventory record should be sought from the Inventory Control Manageris required. Otherwise, approval should be sought from the InventoryControl Officer.13
With Sample ContentUser Requirements Document4.Future Business Process 4.3BP002-UPDATE OF INVENTORY RECORD4.3.1USE CASE DIAGRAM FOR UPDATE OF INVENTORYRECORD Other Use Case Diagram and Business Process Flowchart can be shown below. 14
With Sample ContentUser Requirements Document5Functional RequirementsFUNCTIONAL REQUIREMENTS State the Functional Requirements in this section in numbered tables or paragraphsby grouping them according to business nature or types of requirements and assignedwith a unique requirement number, e.g. REQ- CRE-000, 001, 002, 003, etc. for easeof reference. 5.1LIST OF FUNCTIONAL REQUIREMENTS All functional requirements of the proposed IT system should be listed in thefollowing table and then explained in detail one by one. Each requirement isassigned with a priority to indicate its importance, e.g. MUST (M), SHOULD (S),COULD (C) and WON’T (W). B/D may assign priorities using other ranking, e.g.High, Medium and Low. Table 5 - List of Functional RequirementsReq. IDREQ-CRE-000Requirement TitleCreation of New Inventory RecordTarget UsersREQ-CRE-001Input a new inventory recordREQ-CRE-002Review and approve the record forinvoice amount HK 1MReview and approve the record forinvoice amount HK 1MPrint out the input inventory recordfor checkingUpdate of Selected Inventory RecordInventory ControlAssistantInventory ControlOfficerInventory ControlManagerInventory riorityMMMS REQ-TFR-000Transfer of Inventory .REQ-DPL-000Disposal of Inventory .REQ-TDE-000Trade-in of Inventory .REQ-WRT-000Write off/Replacement of Loss Inventory .REQ-EXE-000Annual Inventory Taking ExerciseREQ-PLB-000Print Bar Code Label15
With Sample ContentUser Requirements DocumentReq. IDREQ-PLB-001Functional RequirementsREQ-INF-000Target UsersInventory ControlAssistantInventory ControlAssistantInterface with the Software Asset Management SystemREQ-INF-001 .REQ-INF-002 .REQ-PLB-0025.2Requirement TitleGenerate bar code label for allitems of an inventory recordPrint bar code labelPriorityMMREQ-CRE-000 CREATION OF NEW INVENTORYRECORD A sample of Requirement Description is shown below. Table 6 - Requirement Description (REQ-CRE-001)ItemRequirement IDDescriptionREQ-CRE-001Requirement TitleInput a new inventory recordPriorityMustFunctional RequirementDescription The Inventory Control Assistant shall be able to create adraft of item record. Each record must have the followinginformation (mandatory fields): 1.Item Category Code2.Item No.3.Purchase Order No.4.Item Description5.Quantity6.Serial No.7.Location8.Owned by (Section)9.Owned by Person10.Date Received11.Item Price in HKDA list of item category code should be provided for user tosearch and select the suitable item category code. Uponselection of an item category code, a list of available itemnumber should be displayed for selection. A “new item”16
With Sample ContentUser Requirements DocumentItemFunctional RequirementsDescriptionlink/button should be provided by opening another screen tocreate a new item category code and item no. and return thenew item code upon creation. If an item is wrongly added, a deletion option should beprovided for removal of the wrongly added item and itscorresponding details. The system should allow scanning of the hardcopy invoiceand/or upload of the softcopy of the scanned invoice to thesystem, and links the invoice to the corresponding inventoryrecord. Since individual items under one inventory record may betransferred to other persons, it is required to link the invoiceto each item instead of the entire inventory record for easeof retrieval and maintenance use. An email will be sent to Inventory Holder and InventoryRecord Administrator to notify that the new item record iscreated. A bar code label will be printed and sent to the InventoryRecord Administrator for sticking the label onto the item.Frequency of UseDailyAcceptance Criteria1.All mandatory fields must be input and checked for validitybefore the new inventory record is created.2.All inventory item category codes and item numbers must becreated and existed in the inventory code master list.3.An email notification should be automatically sent toInventory Holder and Inventory Record Administrator afterthe approved creation of new item record.4.Each inventory item should link with one invoice only.5. Invoice no. should match with an existing PO in which POinvoice is transferred from the e-Procurement System usingdirect purchase or SOA bulk contracts.6.Related BusinessProcess Refer to BP-001.17
With Sample ContentUser Requirements DocumentFunctional Requirements Notes:1.2.3.4.5.6.Requirement ID: Specify a unique ID for each requirement entryRequirement Title: Specify a title for the requirement.Priority: State the priority of the requirement, i.e. “MUST(M)”, “SHOULD(S)”,“COULD(C)” or “WON’T(W)”.Functional Requirement Description: Describe the functional requirement inmore details.Frequency of use: How frequent is the function used on average.Acceptance criteria: Describe how, or to what level of quality the feature shouldbe provided to satisfy the users’ needs. Table 7 - Example of Another Requirement DescriptionItemRequirement IDDescriptionREQ-CRE-002Requirement TitleReview and approve the record for invoice amount HK 1MPriorityMustFunctional RequirementDescription Frequency of Use Acceptance Criteria Related BusinessProcess 18
With Sample ContentUser Requirements Document6Non-Functional RequirementsNON-FUNCTIONAL REQUIREMENTS State the Non-Functional Requirements for the non-functional features such as audit,control and security, global business rules, data requirements, usability requirements,service level targets, user volume and equipment requirements, data growth andretention requirements, etc. that the proposed IT system must possess from a businessperspective. The following proposed non-functional requirements can be changed orremoved to suit project needs. 6.1LIST OF NON-FUNCTIONAL REQUIREMENTSTable 8 - List of Non-Functional RequirementsReq. IDREQ-ACS1REQ-ACS2REQ-ACS3REQ
vi) Non-Functional Requirements such as audit, control and security, global business rules, data requirements, usability requirements, service level targets, user volume and equipment requirements, data growth and retention requirements, etc. sp
Issue of orders 69 : Publication of misleading information 69 : Attending Committees, etc. 69 : Responsibility 69-71 : APPENDICES : Appendix I : 72-74 Appendix II : 75 Appendix III : 76 Appendix IV-A : 77-78 Appendix IV-B : 79 Appendix VI : 79-80 Appendix VII : 80 Appendix VIII-A : 80-81 Appendix VIII-B : 81-82 Appendix IX : 82-83 Appendix X .
Appendix G Children's Response Log 45 Appendix H Teacher's Journal 46 Appendix I Thought Tree 47 Appendix J Venn Diagram 48 Appendix K Mind Map 49. Appendix L WEB. 50. Appendix M Time Line. 51. Appendix N KWL. 52. Appendix 0 Life Cycle. 53. Appendix P Parent Social Studies Survey (Form B) 54
Appendix 5 (MCQ Template) 50 Appendix 6 (EMQ Template) 51 Appendix 7 (SAQ Template) 52 Appendix 8 (OSCE Template) 53 Appendix 9 (Confidentiality and Intellectual Property Statement) 54 CONTENTS. 1 Brief Multiple Choice Questions Brief Introduction to writing one-best Answer MCQs MCQs utilis
Appendix A. Concept Report Template 3.0 3/10/21 Appendix A-1. Revised Concept Report Template 3.0 3/10/21 Appendix A-2. Limited Scope Concept Report Template 3.0 3/10/21 Appendix B. Location and Design Report Template 3.0 3/10/21 Appendix C. Distribution Lists 3.0 3/10/21
Appendix H Forklift Operator Daily Checklist Appendix I Office Safety Inspection Appendix J Refusal of Workers Compensation Appendix K Warehouse/Yard Inspection Checklist Appendix L Incident Investigation Report Appendix M Incident Investigation Tips Appendix N Employee Disciplinary Warning Notice Appendix O Hazardous Substance List
Appendix E: DD Form 577 for Appointing a Certifying Officer 57 Appendix F: Sample GPC Appointment Letters 58 Appendix G: Formal Reporting Requirements 66 Appendix H: Semi-Annual Surveillance Report Template 70 Appendix I: GPC Thresholds 73 Appendix J: Glossary – Sections I and II 75 Chapter 1: The Government Purchase Card Program 1-1. Purpose a.
Initiate a Template-Based Hire – Casual AUPE Hourly (Project) Step 2: Access Template Selection 1. Click the Look up Select Template button (magnifying glass) next to the Select Template field. The Look up Select Template window is displayed. Step 3: Select Template The template
P-245 - Term Contract Template for Gen. Services P-250 - Purchase Order Template P-520 - Equipment Lease Template P-530 - Equipment Maintenance Template P-600 - Professional Services Template P-601 – Professional Services Template (Individuals) P-606 - Chapter 6 Professional Services Template P-650 – Prof. Services Amendment Template
