added requirements

Requirements/Application-Requirements.md

@@ -1,2 +1,28 @@
 # Application Requirements
 
+The following requirements were decided upon to define what OpenTelemetry (OTel)
+signals the application will produce & when support for future SDKs should be
+added:
+
+1. Every supported language that has a GA Traces or Metrics SDK must have at
+   least 1 service example.
+
+    * Mobile support (Swift) is not an initial priority and not included in the
+      above requirement.
+
+2. Application processes must be language independent.
+
+    * gRPC is preferred where available and HTTP is to be used where it is not.
+
+3. Services should be architected to be modular components that can be switched out.
+
+    * Individual services can and should be encouraged to have multiple language
+      options available.
+
+4. The architecture must allow for the possible integration of platform generic
+   components like a database, queue, or blob storage.
+
+    * There is no requirement for a particular component type - at least 1 generic
+      component should be present in general.
+
+5. A load generator must be provided to simulate user load against the demo.

Requirements/OpenTelemetry-Requirements.md

@@ -1,2 +1,24 @@
 # OpenTelemetry Requirements
 
+The following requirements were decided upon to define what OpenTelemetry (OTel)
+signals the application will produce & when support for future SDKs should be
+added:
+
+1. The demo must produce OTel logs, traces, & metrics out of the box for
+   languages that have a GA SDK.
+
+2. Languages that have a Beta SDK available may be included but are not required
+   like GA SDKs.
+
+3. Native OTel metrics should be produced where possible.
+
+4. Both manual instrumentation and instrumentation libraries
+   (auto-instrumentation) should be demonstrated in each language.
+
+5. All data should be exported to the Collector first.
+
+6. The Collector must be configurable to allow for a variety of consumption
+   experiences but default tools must be selected for each signal.
+
+7. The demo application architecture using the Collector should be designed to
+   be a best practices reference architecture.

Requirements/README.md

@@ -1,6 +1,6 @@
 # OpenTelemetry Community Demo Requirements
 
-The following documents capture the Application, OpenTelemetry, and System
+The following documents capture the Application, OpenTelemetry (OTel), and System
 requirements for our shared demo application. These were decided upon in the
 ongoing SIG meeting.
 
@@ -9,3 +9,15 @@ ongoing SIG meeting.
 2. [OpenTelemetry Requirements](./OpenTelemetry-Requirements.md)
 
 3. [System Requirements](./System-Requirements.md)
+
+## Target Personas
+
+We're building the demo application with several different target personas in mind:
+
+1. **Enthusaists** at a company that can use the demo app as an individual to advocate for OTel within their organization.
+
+2. **Developers** with specific language skills who want to see a larger picture view.
+
+3. **APM Vendors** who can evaluate OTel in general or need to produce a demo of their OTel capabilities for customers
+
+4. **Enterprises** considering adopting OTel and interested in understanding what a production-lite experience would be. 

Requirements/System-Requirements.md

@@ -0,0 +1,20 @@
+# System Requirements
+
+To ensure the demo runs correctly please ensure your environment meets the
+following system requirements:
+
+1. Your system must meet the local [Docker](#docker-requirements) requirements
+   or you should use your preferred Cloud Service.
+
+2. The demo must be able to work on the following Operating Systems (OS):
+   Windows, Linux, and Mac with documentation provided for each OS.
+
+## Docker Requirements
+
+Docker requirements for each Operating System can be found below:
+
+1. [Linux](https://docs.docker.com/desktop/linux/install/)
+
+2. [Mac](https://docs.docker.com/desktop/mac/install/)
+
+3. [Windows](https://docs.docker.com/desktop/windows/install/)