Introduce REQUIREMENTS

# Conflicts:
#	README.md

FURPS/TEMPLATE.md

@@ -20,6 +20,6 @@
 
 1. ...
 
-## + (Privacy, Anonymity, Deployments)
+## + (Privacy, Anonymity, Censorship-Resistance, Deployments)
 
 1. ...

REQUIREMENTS.md

@@ -0,0 +1,40 @@
+# Inbound and Outbound Requirements
+
+## Flow
+
+The expected flow (feedback welcome to refine it) is:
+
+1. Project A writes requirements to B (outbound for A, inbound for A) in FURPS+ format.
+2. Project B responds to A's requirements with their own FURPS+ commitments and roadmap,
+   including an overview of which milestones in B's roadmap cover which requirements of A.
+
+Note:
+
+Requirements are negotiable and are state explicitly to enable said negotiation.
+
+B may not be able to deliver all requirements within a half-year,
+a light justification is needed to explain how do we work towards a requirement.
+For example: "Building block x, y, z are necessary, and they are being worked on with milestones 1, 2, 3.
+
+Some requirements may be "rejected" as not considered in scope of B's work, ensuring that further discussion happen
+and requirements are adjusted.
+
+## Inbound to Waku
+
+### Status
+
+TODO: Add link here once Status product document
+
+#### Waku's Response
+
+TODO: Justify here how Status' requirements are being worked towards to with current roadmap.
+
+## Outbound from Waku
+
+### Status
+
+TODO: list specific areas of concerns and risks
+
+### Codex
+
+TODO