Root Cause Analysis

Correct Answer: Revisit the documented requirements and introspect on your team's understanding of them.

When a non-functional requirement fails in User Acceptance Testing (UAT), the first logical step is to 'Revisit the documented requirements and introspect on your team's understanding of them.' Reason being you need to ensure that the team's understanding of the requirement was correct and it was implemented as intendedOn the contrary, blaming the Quality Assurance (QA) team for not identifying the issue earlier doesn't solve the problem but might create hostility and negative team dynamic. Thus, it's not a productive stepStarting to redevelop the requirement from scratch without understanding the root cause of the issue isn't an efficient choice. It doesn't guarantee that the issue won't reoccur, as you might end up making the same mistakes againPushing the issue to the next sprint to not delay the current deliverables is also not recommended. This doesn't resolve the root problem, but just delays it and might affect the next sprint's pace and schedule as the team would need to address the current issue along with the planned work for the next sprint.

Correct Answer: Analyze network performance and traffic patterns

When experiencing intermittent periods of high latency on web applications, the first step you should take is to 'Analyze network performance and traffic patterns'. This allows you to understand if the issue comes from network congestion, issue with a particular application or server, or even a potential security threat. 'Replace the network switches', 'Upgrade the firewall' and 'Add more web servers' could be premature actions and costly without first understanding the root cause. Therefore, prior to implementing any changes, it's necessary to investigate the network and identify what's causing the performance issue.

Correct Answer: Review the server's event logs

The best course of action would be to 'Review the server's event logs'. The event logs can provide significant information about what happened at the time of the issue. For instance, it could have been a temporary network glitch, a transient power event, or a resource contentions on the server. Starting with the logs helps you to diagnose the issue without taking any unnecessarily disruptive actions. The other suggestions like 'Replace the server's network interface card', 'Check the server power supply' or 'Restart the server' should be considered only after initial investigation. They may be disruptive and may not tackle the root cause. Additionally, since access is regained, it's less likely that it's a hardware issue, making those options less probable causes.