diff --git a/docs/testcase_plans.md b/docs/testcase_plans.md
index 7328010..7540bd1 100644
--- a/docs/testcase_plans.md
+++ b/docs/testcase_plans.md
@@ -25,18 +25,21 @@
 
 Positive test-cases:
 
-* Bring-up and verify basic infrastructure assumptions (maybe just that the head-end is available for remote install)
+* Bring-up and verify basic infrastructure assumptions
+  * Head-end is available, configured correctly, and available for software load
+  * Compute notes are available and configured correctly, and available for software load
 * Execute automated deployment of CORD infrastructure and verify baseline state. Various options needs to be supported:
   * Single head-node setup (no clustering)
-  * Triple-head-node setup
-  * Single data-plane up-link from servers
-  * Dual data-plane up-link from servers  
+  * Triple-head-node setup (clustered)
+  * Single data-plane up-link from servers (no high availability)
+  * Dual data-plane up-link from servers (with high availability)
 
 Negative test-cases:
 
 * Verify that deployment automation detects missing equipment
 * Verify that deployment automation detects missing cable
 * Verify that deployment automation detects mis-cabling of fabric and provides useful feedback to remedy the issue
+* Verify that deployment automation detects mis-cabling of servers and provides useful feedback to remedy the issue
 
 ### Baseline Readiness Tests
 
@@ -62,6 +65,7 @@
 * Measure channel surfing experience
 * Replacing RG for existing subscriber
 * Moving existing subscriber to a new address (same RG, new location)
+* Rate at which new subscribers can be added to / removed from the system
 
 Negative test-cases:
 
@@ -84,7 +88,7 @@
 * Power cycling ONU
 * Re-starting RG
 * Power cycling any server (one at a time)
-* Power cycling a fabric switch
+* Power cycling any fabric switch
 * Power cycling any of the VMs
 * Power cycling management switch
 * Replacing a server-to-leaf cable
@@ -123,16 +127,18 @@
 * Number of NBI API requests
 * Subscriber channel change rate
 * Subscriber aggregate traffic load to Internet
-  
+
 In addition to healthy operation, the following is the list contains what needs to be measured quantitatively, as a function of input load:
 
 * CPU utilization per each server
 * Disk utilization per each server
+* Memory utilization per each server
 * Network utilization at various capture points (fabric ports to start with)
 * Channel change "response time" (how long it takes to start receiving bridge traffic as well as real multicast feed)
 * Internet access round-trip time
-  
-  
+* CPU/DISK/Memory/Network trends in relationship to number of subscribers
+* After removal of all subscribers system should be "identical" to the new install state (or reasonably similar)
+
 ### Security Tests
 
 The purpose of these tests is to detect vulnerabilities across the various surfaces of CORD, including:
@@ -179,12 +185,13 @@
 1. Periodically test presence of all processes
 1. Check for stable process ids (rolling id can be a sign of a restarted process)
 1. Periodically capture resource usage, including:
+   * CPU load
    * process memory use
    * file descriptors
    * disk space
    * disk io
    * flow table entries in soft and fabric switches
-   
+
 Final check:
 
 1. Final capture of resource utilization and health report
@@ -204,4 +211,4 @@
 * Verify software inventory (presence and version) of following as applicable
   * DPDK version
   * ovs version
-  * etc.
\ No newline at end of file
+  * etc.