Propose reliability non-functional requirements in the initial readme

This commit introduces reliability nonfunctional requirements
that should be queried during the initial needs analysis for
system design.

These factors readily influence the technological choices a
colleague might make, from the open source services to the
language choices. Capturing them early, and using them to
constrain the design is useful.

The questions are:

== How available does the system need to be?

Designed to capture the desired success rate of the system.
If the system is 99% available, for example, a relatively high
reliability from the dependency (~98 - 99%) can also be expected,
or even higher levels if strategies to overcome intermittent failure
in this service are used (e.g. request hedging).

== How fast does the system need to process requests?

Used to determine whether or not the system can be architected
in an eventually consistent way, or needs a shorter control loop
(such as an RPC system backed by a transactional data store).

== How tolerant of lossy or incorrect data is the business process?

Used to determine what type of data store should be used; what
transactional guarantees that data store should have or where the
application can take shortcuts to make the writes to such a data store
cheaper (such as accepting a request but batching the write).

README.md

@@ -235,6 +235,9 @@ Gather requirements and scope the problem.  Ask questions to clarify use cases a
 * How much data do we expect to handle?
 * How many requests per second do we expect?
 * What is the expected read to write ratio?
+* How available or system need to be?
+* How fast does the system need to process requests?
+* How tolerant of lossy or incorrect data is the business process?
 
 ### Step 2: Create a high level design