The following requirements description for the new ProductionSchedulingSystem was provided to the IT department: The purpose of the new fully automated system is to respond to a customer production order (submitted by the SalesDepartment) by generating a daily production schedule (sent to the Shop Floor Supervisor) and raw material requisitions (sent to the Materials Management Department) for all production orders scheduled for the next day. The list of raw materials and quantities needed for a requisition is contained in a separate bill of materials system. Finally, the system generates job tickets (sent to the Shop Floor Supervisor) for the work to be completed at each workstation during the next day. A fully automated production scheduling system must perform three main functions: 'route an order', 'load a request', and 'generate a production schedule'. To route an order, the system must know which workstations are needed, in what sequence the work must be done, and how much time is required at each workstation to complete the work. This data is available from production route sheets. The 'route an order' function produces a route ticket. The route ticket is an input to the 'load the request' function. Another input is workstation reservations that have already been made, which are contained in workstation load sheets. The result of the 'load the request' function is a new workstation reservation, which is also stored in workstation load sheets. At the end of each day, the workstation reservations are used to 'generate a production schedule'. The results of this function are job tickets and a production schedule. As the IT manager for this project, we tasked a new system analyst to transpose the requirements narrative into a set of diagrams(Context, Use Case with description, and Sequence) that can be reviewed and validated with the users. He showed us the following draft diagrams before sharing them with the users. We noticed some inconsistencies between the diagrams and requirements narrative. While some diagrams were better than others, we felt that improvements should be made to each before sharing them with the customer. We should identify any errors, omissions, inconsistencies, and/or other improvements that should be made to these diagrams before sharing them with the customer. It is NOT necessary to re-draw any of the diagrams, but we should identify the changes made to the diagrams (e.g., in red font) a). Context Diagram:  b). Sequence Diagram:  c). During the review session with the systems analyst, he commented that the second paragraph of the requirements narrative contained some complex workstation reservation steps and actions. He asked if there were other diagrams we would recommend for capturing these requirements. What would we tell him? Explain rationale?